request 2 Target for Synerduino boards - #11756

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

• maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

• maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.

This is an automated suggestion to help route contributions to the appropriate branch.

PR Summary by Qodo

Add SYNERDUINO STM32F405 and H743 board targets (HSE 8/25MHz)

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

Code Review by Qodo

🐞 Bugs (1) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

I suspect the difference between 9.0.1 and 9.1 is #11603 by @daijoubu
I'll defer further comment to him since he presumably understands that work better than I do.

Test firmware build ready — commit 0630280

Download firmware for PR #11756

244 targets built. Find your board's .hex file by name on that page (e.g. MATEKF405SE.hex). Files are individually downloadable — no GitHub login required.

Development build for testing only. Use Full Chip Erase when flashing.

Please correct the PLL1 and PLL2 configuration.

system_stm32h7xx.c:259): pll1Config->m = HSE_VALUE / 1000000 / 2; only works if HSE is a multiple of 2 MHz. With an HSE of 25 MHz, the existing code will incorrectly configure the PLL1 clocks. VCI will be 2.083 MHz instead of 2MHz, VCO will be 1000 MHz instead of 960 MHz and Sysclk will be 500 MHz instead of 480 MHz.
Leaving the VCI a little fast should be fine if you change the n value to get a VCO of 800 MHz. The rest of the clocks in this tree would be fine.

PLL2 had an assert added at system_stm32h7xx.c:500-514, when I fixed the silent bug with the Kakute H7 running at 16 MHz. I knew the code I added only worked for 8 MHz and 16 MHz.

At both locations the easiest will be to add this structure:
#if HSE_VALUE == 25000000
// 25 MHz-specific PLL M/N/R/Q
#else
// Existing code for 8 and 16 MHz HSE
#endif

Thanks for these new Synerduino targets!

I took a look at this with an AI-based tool I have. It may well be wrong on any of the points below — please treat it as a set of questions to check rather than a verdict, and correct me if I've misread something.

I checked out the branch and tried building it to look into a couple of the concerns raised above, and had a few questions.

SYNERDUINOH7 — did it actually build for you?

SYNERDUINOH7/CMakeLists.txt sets HSE_MHZ 25, and target.h also defines USE_SDCARD_SDIO. system_stm32h7xx.c has:

#ifdef USE_SDCARD_SDIO
    // PLL2M = HSE_VALUE / 1600000 pins the VCO input to exactly 1.6 MHz for any HSE.
    STATIC_ASSERT(HSE_VALUE % 1600000 == 0, HSE_not_a_multiple_of_1600000);

25,000,000 % 1,600,000 = 1,000,000, which is nonzero, so I'd expect this to fail to compile for that HSE/SDIO combination. When I tried building SYNERDUINOH7 myself I did get a compile error there:

src/main/common/utils.h:60:18: error: size of array 'assert_failed_HSE_not_a_multiple_of_1600000' is negative
src/main/target/system_stm32h7xx.c:503:5: note: in expansion of macro 'STATIC_ASSERT'
make: *** [Makefile:47626: SYNERDUINOH7] Error 2

yet the CI build worked - weird.

Related to @daijoubu's comment above about the PLL1/PLL2 configuration for a 25 MHz HSE — if I'm reading system_stm32h7xx.c right, pll1Config->m = HSE_VALUE / 1000000 / 2 would also not give the intended VCI/VCO/SYSCLK for a 25 MHz (odd-multiple) HSE, separately from the STATIC_ASSERT above. Would the #if HSE_VALUE == 25000000 special-case he suggested be the right fix for both, or is 25 MHz not actually the real crystal on this board?

Possible USE_IMU_BMI088 mix-up? (SYNERDUINOSTM_F405 and F405A)

Both F405 target.h files enable USE_IMU_BMI088 but the CS pin/bus macros underneath are named BMI160_CS_PIN / BMI160_SPI_BUS, not BMI088_*. As far as I can tell, common_hardware.c only registers a BMI088 bus device when the BMI088_* macros exist — so if that's right, BMI088 wouldn't get detected on these boards as currently written (this matches what the Qodo comment above flagged too). Is this maybe just a copy/paste from the BMI160 block that needs the macro names updated to BMI088_*? Or is BMI088 not actually populated on this board and the USE_IMU_BMI088 line is left over from something else?

Possible DMA collision on S5/S6 (SYNERDUINOSTM_F405 and F405A)?

target.c:40-41 in both F405 targets:

DEF_TIM(TIM1,  CH3,  PA10, TIM_USE_OUTPUT_AUTO, 0, 0), // S5
DEF_TIM(TIM1,  CH2,  PA9,  TIM_USE_OUTPUT_AUTO, 0, 0), // S6

Both use dmaopt=0. If I'm reading timer_def_stm32f4xx.h correctly, the index-0 DMA option for TIM1_CH2 and TIM1_CH3 both land on DMA2 Stream6. Since F405 doesn't have DMAMUX, if that's right it'd mean S5 and S6 contend for the same DMA stream whenever both are active outputs (e.g. any mixer with more than 4 motor/servo channels). Could you check whether that's a real conflict, or whether I'm misreading the DMA option table? If it is real, bumping S6 (TIM1_CH2) to dmaopt=1 looks like it would resolve it, but I haven't verified that myself.

A few smaller things

• Duplicate defines: USE_DSHOT, USE_ESC_SENSOR, and USE_SERIAL_4WAY_BLHELI_INTERFACE each appear twice near the end of target.h in both F405 targets. Doesn't look harmful since the values match, just maybe worth tidying.
• DMA1 Stream0 on H7/H7A: TIM3_CH3 (S1), TIM4_CH3 (S9), and TIM15_CH1 (S11) all use dmaopt=0 in target.c, which looks like it lands all three on DMA1 Stream0. H7 has DMAMUX so this wouldn't be a hard conflict the way the F405 one above might be, but could matter on hex/octo builds or mixes using S1 with S9/S11 together — might be worth double-checking.
• FEATURE_SOFTSERIAL: set in DEFAULT_FEATURES on both F405 targets, but I didn't see any USE_SOFTSERIALn defined — probably just a harmless leftover bit.
• SPI pin naming on SYNERDUINOH7: the earlier Qodo comment about SPI2_SCK_PIN/etc. being defined while USE_SPI_DEVICE_1/BUS_SPI1 is selected shows as resolved, though the code looks unchanged to me. From what I can tell the SPI driver falls back to its built-in SPI1 defaults (PA5/PA6/PA7) when SPI1_*_PIN isn't defined, and those defaults happen to match what's written here — so it may genuinely be fine functionally, just misleadingly named. Wanted to flag it in case that reasoning is wrong.

Really appreciate the work on these targets, especially the dual-gyro "A" variants. Sorry for the wall of questions — happy to be told any/all of this is off base, and glad to help dig into the HSE/PLL2 constants if that ends up being a real issue.

mment to him since he presumably understands that work better than I do.

understood , apparently Ive done some correction on the SPI 1 and SPI 2 pin mixup for the Synerduino H7 boards
it worked on INAV 9.0.1 however same issue on INAV 9.1.0
which keeps calling on the HSE_VALUE % 1600000 Error.

Please correct the PLL1 and PLL2 configuration.

system_stm32h7xx.c:259): pll1Config->m = HSE_VALUE / 1000000 / 2; only works if HSE is a multiple of 2 MHz. With an HSE of 25 MHz, the existing code will incorrectly configure the PLL1 clocks. VCI will be 2.083 MHz instead of 2MHz, VCO will be 1000 MHz instead of 960 MHz and Sysclk will be 500 MHz instead of 480 MHz. Leaving the VCI a little fast should be fine if you change the n value to get a VCO of 800 MHz. The rest of the clocks in this tree would be fine.

PLL2 had an assert added at system_stm32h7xx.c:500-514, when I fixed the silent bug with the Kakute H7 running at 16 MHz. I knew the code I added only worked for 8 MHz and 16 MHz.

At both locations the easiest will be to add this structure: #if HSE_VALUE == 25000000 // 25 MHz-specific PLL M/N/R/Q #else // Existing code for 8 and 16 MHz HSE #endif

let me know where to add it so I can tests on my 25mhz board

oh and that BMI088 issue is corrected now.

@daijoubu @synersignart I took a look at this with an AI-based tool I have. It may well be wrong on any of the points below — please treat it as a suggestion to check rather than a verdict, and correct me if I've misread something.

Following daijoubu's suggested #if HSE_VALUE == 25000000 ... #else ... #endif structure, here's a concrete attempt at both fixes, worked out against the RM0433 PLL register limits and the H743 Rev Y / Rev V VCO ceilings.

src/main/target/system_stm32h7xx.c

PLL1 (~line 259)

#if HSE_VALUE == 25000000
    // 25 MHz HSE has no integer M/N that reaches either RevY's 800 MHz VCO
    // (400 MHz sysclk) or RevV's 960 MHz VCO (480 MHz sysclk) target the way
    // 8/16 MHz crystals do. M=12 gives VCI = 25/12 = 2.083 MHz, still inside
    // the 2-4 MHz RCC_PLL1VCIRANGE_1 selected below. N=384 gives an exact
    // VCO = 25 * 384 / 12 = 800 MHz, so PLLP=2 yields exactly 400 MHz SYSCLK
    // -- the same VCO/output frequencies as RevY's stock config (q=8/r=5 are
    // unchanged, giving the same 100/160 MHz PLL1Q/R outputs).
    // RevV's 480 MHz overclock target (960 MHz VCO) is not reachable from a
    // 25 MHz HSE with a clean integer M/N, so both revisions fall back to the
    // safe, in-spec 400 MHz here -- vos is forced to SCALE1 to match.
    pll1Config->m = 12;
    pll1Config->n = 384;
    pll1Config->vos = PWR_REGULATOR_VOLTAGE_SCALE1;
#else
    pll1Config->m = HSE_VALUE / 1000000 / 2;  // correction for different HSE_VALUE
#endif

Worth noting: with the current code and a 25 MHz HSE, m truncates to 12 while n stays hardcoded at 480 for Rev V silicon, giving a 1000 MHz VCO — that's actually over Rev V's documented 960 MHz ceiling (DS12110 Table 147), not just an off-target frequency. So this isn't only a "wrong clock" bug, it looks like it could be out-of-spec on Rev V boards specifically.

PLL2 (~lines 500-517) — this is the one throwing the HSE_VALUE % 1600000 build error

#ifdef USE_SDCARD_SDIO
#if HSE_VALUE == 25000000
    // 25 MHz HSE has no integer M that pins VCI to exactly 1.6 MHz (would need
    // M=15.625). M=13 gives VCI = 25/13 = 1.923 MHz, still inside the 1-2 MHz
    // RCC_PLL2VCIRANGE_0 selected below. N=416 gives an exact
    // VCO = 25 * 416 / 13 = 800 MHz -- the same VCO as the 8/16 MHz case --
    // so PLL2R/4 = 200 MHz (SDMMC, required by HAL_SD_ConfigWideBusOperation)
    // and PLL2P/2 = 400 MHz below are unchanged.
    RCC_PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_SDMMC;
    RCC_PeriphClkInit.PLL2.PLL2M = 13;
    RCC_PeriphClkInit.PLL2.PLL2N = 416;
#else
    // PLL2M = HSE_VALUE / 1600000 pins the VCO input to exactly 1.6 MHz for any HSE.
    // With N=500 this gives VCO=800 MHz: PLL2R/4=200 MHz (SDMMC), PLL2P/2=400 MHz.
    STATIC_ASSERT(HSE_VALUE % 1600000 == 0, HSE_not_a_multiple_of_1600000);
    RCC_PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_SDMMC;
    RCC_PeriphClkInit.PLL2.PLL2M = HSE_VALUE / 1600000;
    RCC_PeriphClkInit.PLL2.PLL2N = 500;
#endif
    RCC_PeriphClkInit.PLL2.PLL2P = 2; // 400Mhz
    RCC_PeriphClkInit.PLL2.PLL2Q = 3; // 266Mhz - 133Mhz can be derived from this for QSPI if flash chip supports the speed.
    RCC_PeriphClkInit.PLL2.PLL2R = 4; // 200Mhz HAL LIBS REQUIRE 200MHZ SDMMC CLOCK, see HAL_SD_ConfigWideBusOperation, SDMMC_HSpeed_CLK_DIV, SDMMC_NSpeed_CLK_DIV
    RCC_PeriphClkInit.PLL2.PLL2RGE = RCC_PLL2VCIRANGE_0;
    RCC_PeriphClkInit.PLL2.PLL2VCOSEL = RCC_PLL2VCOWIDE;
    RCC_PeriphClkInit.PLL2.PLL2FRACN = 0;
    RCC_PeriphClkInit.SdmmcClockSelection = RCC_SDMMCCLKSOURCE_PLL2;
    if (HAL_RCCEx_PeriphCLKConfig(&RCC_PeriphClkInit) != HAL_OK) {
        Error_Handler();
    }
#endif

The STATIC_ASSERT daijoubu added for the Kakute H7 16 MHz fix stays intact — it's still guarding the 8/16 MHz path, just no longer wrongly applied to the 25 MHz case it was never meant to cover.

Caveats

• Not built or measured on hardware on my end — @synersignart, if you can flash this and check actual SYSCLK (e.g. via MCO1/MCO2 out to a frequency counter, or just confirm it boots and SD card / OSD work), that'd be the real verification.
• This deliberately gives up Rev V's 480 MHz overclock for 25 MHz-HSE boards, falling back to the safe, in-spec 400 MHz for both silicon revisions. A tighter fit exists if you want to chase the Rev V ceiling later (M=13, N=499 gets VCO≈959.6 MHz, sysclk≈479.8 MHz) — but that felt like a separate follow-up rather than something to bundle into this fix.

Let me know if this checks out or if I've misread the register constraints anywhere — happy to help dig further if not.

@daijoubu @synersignart I took a look at this with an AI-based tool I have. It may well be wrong on any of the points below — please treat it as a suggestion to check rather than a verdict, and correct me if I've misread something.

Following daijoubu's suggested #if HSE_VALUE == 25000000 ... #else ... #endif structure, here's a concrete attempt at both fixes, worked out against the RM0433 PLL register limits and the H743 Rev Y / Rev V VCO ceilings.

src/main/target/system_stm32h7xx.c

PLL1 (~line 259)

#if HSE_VALUE == 25000000
    // 25 MHz HSE has no integer M/N that reaches either RevY's 800 MHz VCO
    // (400 MHz sysclk) or RevV's 960 MHz VCO (480 MHz sysclk) target the way
    // 8/16 MHz crystals do. M=12 gives VCI = 25/12 = 2.083 MHz, still inside
    // the 2-4 MHz RCC_PLL1VCIRANGE_1 selected below. N=384 gives an exact
    // VCO = 25 * 384 / 12 = 800 MHz, so PLLP=2 yields exactly 400 MHz SYSCLK
    // -- the same VCO/output frequencies as RevY's stock config (q=8/r=5 are
    // unchanged, giving the same 100/160 MHz PLL1Q/R outputs).
    // RevV's 480 MHz overclock target (960 MHz VCO) is not reachable from a
    // 25 MHz HSE with a clean integer M/N, so both revisions fall back to the
    // safe, in-spec 400 MHz here -- vos is forced to SCALE1 to match.
    pll1Config->m = 12;
    pll1Config->n = 384;
    pll1Config->vos = PWR_REGULATOR_VOLTAGE_SCALE1;
#else
    pll1Config->m = HSE_VALUE / 1000000 / 2;  // correction for different HSE_VALUE
#endif

Worth noting: with the current code and a 25 MHz HSE, m truncates to 12 while n stays hardcoded at 480 for Rev V silicon, giving a 1000 MHz VCO — that's actually over Rev V's documented 960 MHz ceiling (DS12110 Table 147), not just an off-target frequency. So this isn't only a "wrong clock" bug, it looks like it could be out-of-spec on Rev V boards specifically.

PLL2 (~lines 500-517) — this is the one throwing the HSE_VALUE % 1600000 build error

#ifdef USE_SDCARD_SDIO
#if HSE_VALUE == 25000000
    // 25 MHz HSE has no integer M that pins VCI to exactly 1.6 MHz (would need
    // M=15.625). M=13 gives VCI = 25/13 = 1.923 MHz, still inside the 1-2 MHz
    // RCC_PLL2VCIRANGE_0 selected below. N=416 gives an exact
    // VCO = 25 * 416 / 13 = 800 MHz -- the same VCO as the 8/16 MHz case --
    // so PLL2R/4 = 200 MHz (SDMMC, required by HAL_SD_ConfigWideBusOperation)
    // and PLL2P/2 = 400 MHz below are unchanged.
    RCC_PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_SDMMC;
    RCC_PeriphClkInit.PLL2.PLL2M = 13;
    RCC_PeriphClkInit.PLL2.PLL2N = 416;
#else
    // PLL2M = HSE_VALUE / 1600000 pins the VCO input to exactly 1.6 MHz for any HSE.
    // With N=500 this gives VCO=800 MHz: PLL2R/4=200 MHz (SDMMC), PLL2P/2=400 MHz.
    STATIC_ASSERT(HSE_VALUE % 1600000 == 0, HSE_not_a_multiple_of_1600000);
    RCC_PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_SDMMC;
    RCC_PeriphClkInit.PLL2.PLL2M = HSE_VALUE / 1600000;
    RCC_PeriphClkInit.PLL2.PLL2N = 500;
#endif
    RCC_PeriphClkInit.PLL2.PLL2P = 2; // 400Mhz
    RCC_PeriphClkInit.PLL2.PLL2Q = 3; // 266Mhz - 133Mhz can be derived from this for QSPI if flash chip supports the speed.
    RCC_PeriphClkInit.PLL2.PLL2R = 4; // 200Mhz HAL LIBS REQUIRE 200MHZ SDMMC CLOCK, see HAL_SD_ConfigWideBusOperation, SDMMC_HSpeed_CLK_DIV, SDMMC_NSpeed_CLK_DIV
    RCC_PeriphClkInit.PLL2.PLL2RGE = RCC_PLL2VCIRANGE_0;
    RCC_PeriphClkInit.PLL2.PLL2VCOSEL = RCC_PLL2VCOWIDE;
    RCC_PeriphClkInit.PLL2.PLL2FRACN = 0;
    RCC_PeriphClkInit.SdmmcClockSelection = RCC_SDMMCCLKSOURCE_PLL2;
    if (HAL_RCCEx_PeriphCLKConfig(&RCC_PeriphClkInit) != HAL_OK) {
        Error_Handler();
    }
#endif

The STATIC_ASSERT daijoubu added for the Kakute H7 16 MHz fix stays intact — it's still guarding the 8/16 MHz path, just no longer wrongly applied to the 25 MHz case it was never meant to cover.

Caveats

* Not built or measured on hardware on my end — @synersignart, if you can flash this and check actual SYSCLK (e.g. via `MCO1`/`MCO2` out to a frequency counter, or just confirm it boots and SD card / OSD work), that'd be the real verification.

* This deliberately gives up Rev V's 480 MHz overclock for 25 MHz-HSE boards, falling back to the safe, in-spec 400 MHz for both silicon revisions. A tighter fit exists if you want to chase the Rev V ceiling later (M=13, N=499 gets VCO≈959.6 MHz, sysclk≈479.8 MHz) — but that felt like a separate follow-up rather than something to bundle into this fix.

Let me know if this checks out or if I've misread the register constraints anywhere — happy to help dig further if not.

thanks , we'll try it over the weekend . let you know how it goes
also can you reconstruct the whole src/main/target/system_stm32h7xx.c
I have no idea where PLL1 goes

Just to clarify, the STATIC_ASSERT is there to catch anyone that added a new target with an HSE that is not 8 or 16 MHz rather than building with a misconfigured clock. There should be a similar one on the PLL1 clock tree as well. AI misread the purpose of the assert. It only allows targets to compile if they will result in the intended clock speeds.

I have a task in my backlog to review the flash wait states for Rev V vs Rev Y and will probably add the check for a supported HSE frequency to PLL1 if I need to make any changes there as well at that time.

See attached. I have not tested this.

system_stm32h7xx.c